1. Field of the Invention
The present invention relates to systems and methods for determining the proper functioning status of listening processes for monitoring communications between electronic components connected via a network. More particularly, the present invention relates to systems and methods for determining the operational status of listening processes that receive information regarding changes in downstream architecture and relay such information upstream using a CORBA interface.
2. Background of the Invention
In the increasingly sophisticated field of electronic communication, particularly between electronic systems or machines, the TL-1 line protocol has remained a common industry standard. TL-1 lines are used as a communication medium between different electronic systems or machines, particularly in Internet- and telecommunication-related systems. However, TL-1 commands are typically very specific and limited to the type of systems or machines that utilize such lines. For example, each distinct system component may require its own unique TL-1 commands or inputs that take into account the specifics of the particular component.
Such a need for detailed characteristics makes use of TL-1 commands generally complicated and time-consuming. Further, TL-1 commands used by different system components make it difficult for the components to communicate with one another, even though all use the general TL-1 command protocol. Finally, much detail is required to determine the specific programming characteristics of each hardware component that is being connected with a given TL-1 line. Thus, although ubiquitously used, TL-1 lines have a number of limiting characteristics.
One of the most limiting characteristics of a TL-1 line is that it does not allow for efficient communication between interconnected hardware. For example, if a change is made in a downstream component of an electronic system, it would be very difficult for an upstream component to receive “real-time” information about that specific downstream change. Typically, when a downstream change is currently made to, for example, a component of a system, such change is communicated to an upstream programmer by the person who has made such a change in the downstream component. Such a requirement for the person who creates changes to communicate them “manually” to upstream programmers is inefficient and prone to errors, such as when the person forgets to relay such information to upstream programmers.
As a further non-limiting example, if an electronic switch or card is changed in a downstream component of an electronic network, TL-1 lines connecting the series of network components to an upstream programmer would not efficiently allow the programmer to be cognizant of the change. Such a programmer may receive some indication that a change was made in that specific downstream component if the programmer sends a specific command related to that changed component and the component responds, because of the change, in a way that the programmer was not expecting. This conventional “reactive” method of determining changes downstream is inefficient and prone to errors, particularly when the upstream programmer is not aware of the downstream changes.
Thus, there is a need for systems or methods that automatically update the status of a system architecture as it changes in “real time” in an effective and efficient manner. Additionally, there is a further need for a central processing center to receive all the information from downstream components, and reforms the information into a universal language that is understandable by an upstream component. To that end, there is a need for an automated system health checker that determines whether the communication pathways between the downstream components and the central processing center is viable or not.